Web Cache

A web cache is a system that temporarily stores copies of web resources (HTML pages, images, CSS, JavaScript, etc.) to serve them faster on future requests. Its located between the origin server and user. When a user requests a website or static resource the request is first send to the cache, if there's not copy of the resource there it results in a MISS or cache MISS. The request is then forwarded to the origin server which responds to the request. The response is sent to the cache.

Whether the server should send a cached response or forward the request to the origin server. The cache decides on this by generating a cache key based on element in the request, like URL paths, query parameter or other HTTP headers.

Cache Key example:

There are keyed and unkeyed parameters in the Cache key. In example below the keyed parameter in thet GET requests differ, while user-agent and accept are unkeyed.

To inject malicious payloads into the web cache we need unkeyed parameters because keyed need to be the same when the victim access the resources.

Payload in unkeyed ref parameter

If user makes request after that like below it will get the XSS payload.

X-Cache-Status

This header will tell if the response was cached or not. If this header is not present you have to find it manually by changing parameters and checking the responses.

Testing content parameter

Since the content parameter is different but still get a cache hit, its unkeyed. Would the third request it be a miss it tells the cache key was different from the first 2 request, and thus its keyed.

In case of XXS vulns we can send this request twice to cache the payload then

This visit to trigger the payload: http://94.237.50.221:52841/index.php?language=go

Is the process of mapping URL paths with resources on a server; like files, scripts, commands for example http://example.com/path/in/filesystem/resource.html. We can create discrepancies by sending a url like

The origin server will ignore test.css and returns profile for user 123 The web cache using URL mapping will cache and server the profile for user 123. But the cache needs to be configured to store responses for request where path ends in .css.

How to test how the origin server maps URLs Test if you still get information back after changing the /api/product/123 to /api/product/123/foo./pro

This exercise is from portswigger. We start by finding an interesting endpoint where look for a discrepancy by changing the url. The original request we have:

Trying to change the url by usin test or test.js it still returns the account page.

Looking at the response we see X-Cache: miss. Meaning the page isn't cached, however since we sent the request the page is now cached. And if we send the request again it says X-Cache: hit.

To use this we can send the victim a fresh URL to cache like /my-account/test.js. If the victim has opened the link we can open the URL ourselves and we will get the response of the victim which was cached.

The victim will open the cached acount page exposing sensitive information.\

A delimiter is a character or sequence of chars to separate or mark boundaries in data. In url we see ? for example. Discrepancies in how a cache or origin server use delimiters can result in web cache deception. For example Java Spring used ; but other frameworks don't use the ;. So a cache that doesn't use Java Spring is likely to interpret ; and everything after it as part of the path.

Finding delimiter chars

Fuzz chars and specials char in the path. /users/test/list to /users/test/lista and use this response to find the delimiter by adding a possible char between. /settings/test/list;aaa . If the response is identical to the base response, this indicates that the ; character is used as a delimiter.

If you found delimiters used by the origin server, add a static extension to the end and see if the response is cached.

The origin server returns the dynamic profile information, which is stored in the cache.

For example we can send a request after having found delimiter ;

We get back, showing a miss in the cache

We now have url which is cached so create a fresh url and send it to the victim.

When the victim clicks it will result in a HIT and the response is cached which we can retrieve by opening the url.

The cache and server can read the same URL different when one decodes special chars and the other doesn't. %23 is the encoded version of #

Web servers often store resrources in specific directories:

Normalization is converting representations of a URL into a standardized format.

Differences in how the origin server and the cache normalize URL's can enable attackers to create a path traversel payload which is treated different by each parser. Example: /static/..%2fprofile.

fat GET

We can use fat GET request where we use parameters in the body of the request. Below request would get german language instead of english confirming fat GET requests

The Host header tells the web server which website/domain the client wants to access when multiple sites are hosted on the same server. Like in the example below:

In our request we see

In case of local attacks you can fuzz ip's in the Host Header with 192.168.***.***

So a request could look like, where's X-Host send twice to poison cache.

Its possible there's a filter in place that checks for pre-configured domains. Trying another domain may result in an error as the domain is not in the pre-configuration file.

Port bypass

Applications may run on a non-default port during testing so trying any other port might bypass the header check.

Blacklist bypass

Using blacklist a app might block localhostand 127.0.0.1 but by simple encoding the address like 0x7f000001 we can bypass the check.